Software running on a processor or central processing unit (CPU) to provide functionality in the host device often changes over time. The changes may result from the need to correct bugs, or errors, in the software files, adapt to evolving technologies, or add new features and functions. In particular, embedded software components hosted on mobile wireless devices often include numerous software bugs that require correction.
Software includes one or more files in the form of human-readable American Standard Code for Information Interchange (ASCII) plain text files or binary code. Software files can be divided into smaller units that are often referred to as modules or components. A UNIX platform or personal computer (PC) includes multiple software components, and each of the software components is managed and updated independently through a file system supported by a corresponding operating system (OS). Information used to update software files or software components hosted on UNIX platforms or PCs can be transferred through the Internet or loaded from a secondary storage medium such as a floppy disk, a compact disk read-only memory (CD-ROM), or a compact flash card.
In contrast, in mobile wireless devices, a real-time operating system (RTOS) is typically used in which all software components are linked as a single large file. Further, no file system support is typically provided in these mobile wireless devices. In addition, the single large file needs to be loaded, or embedded, into the device and updated using a wireless communication link or over-the-air (OTA) link like a radio link. Consequently, problems arise with regard to delivering software file updates to mobile devices like cellular telephones and other mobile communication devices, personal digital assistants (PDAs), and personal computers.
One solution to the problem of delivering large files to mobile devices for use in updating files of the mobile devices uses difference programs to generate difference files. The difference files include data that describes how a revised or new file differs from an original file. While use of the various difference programs helps reduce the size of the transferred files, issues remain as to the reliability associated with provision of the updates to the mobile devices.
For example, file delivery and updating via an OTA link carries with it an increased probability of failure. These failures generally relate to failures associated with components of the service provider network and/or components of the numerous mobile devices that must receive the updates. Examples of the types of failures that can occur include mobile device hardware failures, software failures, failures relating to power (battery) exhaustion, and failures as a result of disconnections of the mobile device from the network during the update process. Regardless of the cause of the update failure device manufacturers and service providers must ensure, when providing software updates to the mobile devices via over-the-air (OTA) connections, that the mobile device is completely recoverable in the event of failures during the update process.
In the drawings, the same reference numbers identify identical or substantially similar elements or acts. To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the Figure number in which that element is first introduced (e.g., element 116 is first introduced and discussed with respect to FIG. 1).
Unless described otherwise below, the construction and operation of the various blocks and structures shown in the Figures are of conventional design. As a result, such blocks need not be described in further detail herein, because they will be understood by those skilled in the relevant art. Such further detail is omitted for brevity and so as not to obscure the detailed description of the invention. Any modifications necessary to the Figures can be readily made by one skilled in the relevant art based on the detailed description provided herein.
Referring to FIGS. 3, 4, 5A, 5B, 7A, 7B, 9, and 11-14, the operations of the flow diagrams are under control of at least one processor, but are not so limited. Each of the blocks depicted in these flow diagrams is of a type well known in the art, and can itself include a sequence of operations that need not be described herein. Those skilled in the relevant art can create source code, microcode, program logic arrays or otherwise implement the invention based on these flow diagrams and the detailed description provided herein. The algorithm or routine operating according to these flow diagrams is stored in non-volatile memory (not shown) that forms part of the associated processors, in the associated memory areas, in removable media (not shown), such as disks, or hardwired or preprogrammed in chips (not shown), such as EEPROM semiconductor chips, or in any combination of these components, but is not so limited.